1. Field of Invention
This invention relates to generation, from graphically produced description of workflow process, of source code and compiling and linking instructions of fully executable transactional workflow application with adaptive high-performance capacity for transactional processing of concurrent workflow and its real-time visualization.
Graphically produced description of workflow process represents flow of control between activities included in the workflow process and software components, providing activities' functionality. Generated source code and compiling and linking instructions are used to build transactional workflow application's fully executable code. This way produced executable code is ready to be loaded in computer memory code segments and, after code loading, to run the application by invoking the code loaded in code segments. Foundation of the adaptive high-performance capacity is a hierarchical tree of class objects with ability to represent variety of workflow configurations, and associated to it hierarchical structure of threads, supported by apparatus preventing and neutralizing development of software bottlenecks. The adapting of performance capacity relates to ability to automatically allocate and deallocate system resources, in support to workflow processing, based on application self-assessment of its needs. The extent of application's high-performance capacity is restricted only by environmental factors limiting its self-expansion, such as availability of unused system memory and unused CPU power, and by ability of networking infrastructure to cope with generated traffic.
2. Introduction and Prior Art
In his book discussing next stage of e-business revolution “After the Internet: Alien Intelligence” published in year 2000, James Martin argues that corporations will become part of a broad-ranging global ecosystem involving electronic linkage of diverse enterprises. Electronically linked in ecosystem where everything happens fast, corporations will need capability of reacting in real-time to changes in its environment, competition and customer needs. In that context speed, being an imperative for survival and growth, has two aspects: speed of interaction with partners and customers, and speed of adapting to changes.
Customer-facing e-business applications are expected to respond in realtime to customer requests, to initiate and conduct simultaneous processing of unpredictably high number of user interactions, and be processing-centric, i.e. capable of executing set of related actions structured as transactional workflow. Eventual execution as single transaction, instead as transactional workflow, of all actions related to responding to a step of single user interaction will hold database locks until the transaction is completed or aborted. As a result, even when multiple instances of the same e-business application run concurrently, these instances will perform sequentially—one will hold database locks and all other will wait for database locks to be released. Therefore, the only way to cone with both increased number of concurrent users and increased processing complexity of user interactions while preserving real-time responsiveness is to use workflow systems with capacity for processing of high-volume concurrent transactional workflow.
Ability to adapt to changes in environment, competition, and customer needs implies high-speed of development of e-business systems and flexibility of existing e-business systems for future finegrain changes within limited time. The most flexible solutions, created with known technologies, satisfying those two requirements, are in form of workflow engine, workflow script and workflow activities' software components. A workflow script is a form of description of workflow graph representing sequence of execution of workflow activities. During workflow application running, workflow engine interprets workflow graph description and this results in execution of software components, representing workflow activities, in described sequence. If modifications of a workflow process are needed, desired results are achievable with changes in workflow graph, or components, or both. United States Patent Documents 20020040339, 20020065701, 20020170035, and 20020184616 demonstrate prior art related to concept of workflow engines.
Such flexibility, however, has its price. The price is low efficiency of consumed resources, low processing speed, and lack of concurrency. Even if a hypothetical generic solution, in form of workflow engine, script and components, has ability for concurrent processing of multiple requests, no such solution can compete in respect to efficiency and speed with a proprietary executable application, designed and built for a particular workflow process. What may contribute to increasing workflow application efficiency and speed is any partial or full replacement of interpreted code with executable. Replacement of interpreted code with executable is the approach used with some Java Virtual Machine (JVM) based application servers. The performance improvement, however, does not extend over workflow concurrency because of the inherent concurrency limitations of JVM. With JVM application servers, the only way to process 2 workflow requests concurrently is to concurrently run 2 workflow application instances.
Powerful formal method of development of customizable application source code, for compiling and linking into executable code, is the method of declarative programming. This method allows developers to control, for example, behavior of a class by setting attribute values and by separation of configuration and customization data from class source code. Declarative programming does not require usage of object-oriented languages; it could be a design principle in creation of any application. Prior art exemplifying the concept of declarative programming is demonstrated by technology described in United States Patent Document 20020029376. Workflow engines might arguably be regarded as extreme results of declarative programming and related to it software design concepts.
Another formal method of standardizing software development process is the template-based development of customizable application source code. In contrast to data-driven declarative programming, where software customization happens at run time, implementation of templates performs customization of source code at compile time. This is a strong point in respect to effectiveness of the produced executable code. Price for this effectiveness is reduced flexibility. Unlike the data-driven programming, not all software variations could be expressed with templates.
High-performance capacity for transactional workflow processing means fast and concurrent processing of virtually all simultaneously arriving individual requests for work. Replacement of interpreted code with executable is the first assumed requirement and proposed step in direction of obtaining desired high-performance capacity. In multi-threading operating system environment, concurrent processing is achievable by creation of sufficient number of threads at each workflow-activity that is part of a workflow process. Therefore, naturally appearing second requirement is to ensure that sufficient number of threads are created and loaded with units of work smoothly and with no delays. Workflow application, experiencing insufficiency of threads or experiencing delays with loading threads with work at any point of the workflow-process, develops software related workflow bottlenecks.
Main reason for software related bottlenecks in a workflow application, processing high-volumes of workload in distributed environment, is application's inability to adjust at run-time the quantity and structure of threads assigned to each one of application's workflow-activities. Quantity and structure of threads should correspond to application needs. Application needs, however, are variable due to variability of working conditions they reflect. Run-time adjustment of threads' structure and quantity is, therefore, the third requirement. Application's working conditions variability might be due to invocation of procedures with response time being function of unpredictable external conditions. For example, invocation of distributed procedure during network congestion or variable response time of services provided by external organizations. Or might be due to unexpectedly high volume of simultaneously arriving requests for work.
Finally, the fourth requirement is to ensure efficient use of system resources. Created workflow application must be able to adapt to different directions of changes in working environment and changing workload. Efficient use of system resources will be ensured when adaptation processes are not single directional and not limited to threads' restructuring only. Therefore, workflow application should be able to expand itself when and where more processing power is needed and to contract itself when and where the additionally acquired processing power is not used.